Fix ORCA direct dispatch for multi-value quals#1852
Open
zhangwenchao-123 wants to merge 1 commit into
Open
Conversation
Contributor
|
It looks like we see some issues in tests, see: |
Contributor
Author
Got it, will fix. |
zhangwenchao-123
force-pushed
the
fix_orca_multivalue_direct_dispatch
branch
from
July 17, 2026 06:09
03b688a to
0cb2bd8
Compare
For a predicate restricting the distribution key to several constants,
e.g. WHERE dist_key IN (c1, c2), the Postgres planner direct-dispatches
the slice to the union of the segments the constants hash to. GPORCA
gave up instead: the optimizer side already emits one datum array per
value into CDXLDirectDispatchInfo, but TranslateDXLDirectDispatchInfo
required every value to hash to the same segment and returned NIL
otherwise, so the query was dispatched to all segments.
Collect the distinct content ids of all datum combinations instead,
mirroring the planner's MergeDirectDispatchCalculationInfo behavior.
A value set that spans every segment still returns NIL, since direct
dispatch buys nothing there. PlanSlice->directDispatch.contentIds is
already a list and the dispatcher handles multiple content ids, so no
dispatcher change is needed. Add a gpdb::LAppendUniqueInt wrapper for
list_append_unique_int.
On a 3-segment cluster, "select * from t1_varchar where col1_varchar
in ('a','b')" now dispatches to 2 segments (PARTIAL contents) instead
of all 3, matching the planner. Single-value and same-segment cases
are unchanged, as is the raw-values gp_segment_id path. Update the
affected expected outputs: the direct_dispatch disjunction scenarios,
the bfv_dd dispatch INFO lines, and the plans in create_index,
inherit, partition, partition_append, partition_prune,
partition_prune_append and qp_misc_jiras whose Gather Motion drops
from 3:1 to 2:1, in src/test/regress as well as in the copies of
these tests carried by the pax_storage and vectorization suites.
zhangwenchao-123
force-pushed
the
fix_orca_multivalue_direct_dispatch
branch
from
July 17, 2026 09:20
0cb2bd8 to
554f458
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For a predicate restricting the distribution key to several constants, e.g. WHERE dist_key IN (c1, c2), the Postgres planner direct-dispatches the slice to the union of the segments the constants hash to. GPORCA gave up instead: the optimizer side already emits one datum array per value into CDXLDirectDispatchInfo, but TranslateDXLDirectDispatchInfo required every value to hash to the same segment and returned NIL otherwise, so the query was dispatched to all segments.
Collect the distinct content ids of all datum combinations instead, mirroring the planner's MergeDirectDispatchCalculationInfo behavior. A value set that spans every segment still returns NIL, since direct dispatch buys nothing there. PlanSlice->directDispatch.contentIds is already a list and the dispatcher handles multiple content ids, so no dispatcher change is needed. Add a gpdb::LAppendUniqueInt wrapper for list_append_unique_int.
On a 3-segment cluster, "select * from t1_varchar where col1_varchar in ('a','b')" now dispatches to 2 segments (PARTIAL contents) instead of all 3, matching the planner. Single-value and same-segment cases are unchanged, as is the raw-values gp_segment_id path. Update the affected expected outputs: the direct_dispatch disjunction scenarios, the bfv_dd dispatch INFO lines, and the plans in create_index, inherit, partition, partition_append, partition_prune, partition_prune_append and qp_misc_jiras whose Gather Motion drops from 3:1 to 2:1, in src/test/regress as well as in the copies of these tests carried by the pax_storage and vectorization suites.
Fixes #1839
What does this PR do?
Type of Change
Breaking Changes
Test Plan
make installcheckmake -C src/test installcheck-cbdb-parallelImpact
Performance:
User-facing changes:
Dependencies:
Checklist
Additional Context
CI Skip Instructions